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Foreword 



The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



rd , 



The present document is part of a TS-family covering the 3"^ Generation Partnership Project: Technical Specification 
Group Services and System Aspects; Telecommunication management; as identified below: 

32.111-1 "Fault Management; Part 1 : 3G fault management requirements" . 

32.111-2 "Fault Management; Part 2: Alarm Integration Reference Point (IRP): Information Service 

(IS)". 

32. 111-3 "Fault Management; Part 3: Alarm Integration Reference Point (IRP): Common Object Request 

Broker Architecture (CORBA) Solution Set (SS)". 

32. 111-4 "Fault Management; Part 4: Alarm Integration Reference Point (IRP): Common Management 

Information Protocol (CMIP) Solution Set (SS)". 

The present document is part of a set of TSs which describe the requirements and information model necessary for the 
Telecommunication Management (TM) of 3G systems. The TM principles and TM architecture are specified in 
3GPP TS 32.101 [12] and 3GPP TS 32.102 [13]. 

A 3G system is composed of a multitude of Network Elements (NE) of various types and, typically, different vendors 
inter-operate in a co-ordinated manner in order to satisfy the network users' communication requirements. 
The occurrence of failures in a NE may cause a deterioration of this NE's function and/or service quality and will, in 
severe cases, lead to the complete unavailability of the NE. In order to minimise the effects of such failures on the 
Quality Of Service (QOS) as perceived by the network users it is necessary to: 

• detect failures in the network as soon as they occur and alert the operating personnel as fast as possible; 

• isolate the failures (autonomously or through operator intervention), i.e. switch off faulty units and, if applicable, 
limit the effect of the failure as much as possible by reconfiguration of the faulty NE/adjacent NEs; 

• if necessary, determine the cause of the failure using diagnosis and test routines; and, 

• repair/eliminate failures in due time through the application of maintenance procedures. 

This aspect of the management environment is termed "Fault Management" (FM). The purpose of FM is to detect 
failures as soon as they occur and to limit their effects on the network Quality of Service (QOS) as far as possible. 
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The latter is achieved by bringing additional/redundant equipment into operation, reconfiguring existing 
equipment/NEs, or by repairing/ehminating the cause of the failure. 

Fault Management (FM) encompasses all of the above functionalities except commissioning/decommissioning of NEs 
and potential operator triggered reconfiguration (these are a matter of Configuration Management (CM), cf. 
3GPPTS 32.106 [1]). 

FM also includes associated features in the Operations System (OS), such as the administration of a pending alarms list, 
the presentation of operational state information of physical and logical devices/resources/functions, and the provision 
and analysis of the alarm and state history of the network. 
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Scope 



The present document defines the Alarm Integration Reference Point (IRP) Information Service (IS), which addresses 
the alarm surveillance aspects of Fault Management (FM), applied to the N Interface between EM-NM and NE-NM. 

The purpose of the Alarm IRP is to define an interface through which a "system" (typically a Network Element 
Manager or a Network Element) can communicate alarm information for its managed objects to one or several Manager 
Systems (typically Network Management Systems). 

The Alarm IRP IS defines the semantics of alarms and the interactions visible across the reference point in a protocol 
neutral way. It defines the semantics of the operations and notifications visible in the IRP. It does not define the syntax 
or encoding of the operations, notifications and their parameters. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[I] ITU-T Recommendation Q821: "Stage 2 and Stage 3 description for the Q3 interface - Alarm 
surveillance". 

[2] ITU-T Recommendation X.733 (02/92): "Information technology - Open Systems Interconnection 

- Systems management: Alarm Reporting Function". 

[3] ITU-T Recommendation X.721: "Information Technology - Open Systems Interconnection - 

Structure Of Management Information: Definition Of Management Information". 

[4] ITU-T Recommendation X.736: "Security Alarm Reporting Function". 

[5] ITU-T Recommendation X.732: "Relationship Management Function". 

[6] ITU-T Recommendation X.73 1 : "State Management Function". 

[7] ITU-T Recommendation X. 730: "Object Management Function". 

[8] ITU-T Recommendation X.720: "Management Information Model". 

[9] ITU-T Recommendation M.3100 (07/95): "Generic network information model". 

[10] GSM 12.11 version 6.2.0 Release 1997: "Fault management of the Base Station System (BSS)". 

[II] 3GPP TS 32.106-2: "Telecommunication management; Configuration Management (CM); Part 2: 
Notification Integration Reference Point (IRP): Information Service (IS)". 

[12] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[13] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[14] 3GPP TS 32.106-8: "Telecommunication management; Configuration Management (CM); Part 8: 

Name convention for Managed Objects". 

[15] 3GPP TS 32.1 1 1-1: "Telecommunication management; Fault Management; Part 1: 3G fault 

management requirements". 
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[16] 3GPP TS 32.1 1 1-3: "Telecommunication management; Fault Management; Part 3: Alarm 

Integration Reference Point (IRP): Common Object Request Broker Architecture (CORBA) 
Solution Set (SS)". 

[17] 3GPP TS 32.1 1 1-4: "Telecommunication management; Fault Management; Part 4: Alarm 

Integration Reference Point (IRP): Common Management Information Protocol (CMIP) Solution 

Set(SS)". 



Definitions and abbreviations 



3.1 Definitions 



In addition to the terms and definitions defined in 3GPP TS 32.111-1 [15], the following definitions apply to the present 
document: 

Acknowledge alarm: It is functionality provided to facilitate the management of alarms. The definition of the practical 
activity associated to the alarm acknowledgement is outside the scope of this IRP. The alarm acknowledgement process 
is summarised as follows: 

IRP Agent, when first reports an alarm to IRPManager, will set the alarm's Acknowledgement State to 
unacknowledged. IRPManager, on behalf of the user (e.g. operator), can set the state to acknowledged by 
supplying (a) identifier of user acknowledging the alarm and (b) identifier of management system on which 
IRPManager runs. IRP Agent records the two pieces of information and the time of acknowledgement in Alarm 
Information of Alarm List. IRPManager representing a human operator can initiate acknowledge alarm request. 
IRPManager, representing an authorized management application, can initiate acknowledge alarm request as well. 

Alarm List: It contains a list of Alarm Information whose severity level is not Cleared, or severity level is Cleared 
but is not yet Acknowledged. IRP Agent maintains the Alarm List. 

Correlated Notifications: It contains a set of Notification identifiers. It may be present as a parameter of Notification. 
If present, the set of Notifications identified by Correlated Notifications and the subject Notification are related 
(correlated). 

Event: It is an occurrence that is of significance to network operators, the NEs under surveillance and Network 
Management applications. Events do not have state. 

IRPManager: defined in 3GPP TS 32.102 [13]. 

Notification: It refers to the transport of events from IRP Agent to IRPManager. In this IRP, notification is used to 
carry alarm information from IRP Agent to IRPManager. 

Notification Identifier: It provides an identifier for the notification, which may be carried in the Correlated 
Notifications parameter (see below) of future notifications. Notification identifiers shall be chosen to be unique across 
all notifications of a particular managed object (representing the NE) throughout the time that correlation is significant. 
Notification carries this identifier in parameter called not i float ion Id. The algorithm by which correlation is 
accomplished is outside the scope of this IRP. 

IRPAgent: defined in 3GPP TS 32.102 [13]. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AIR Alarm Information Reference 

CCITT The International Telegraph and Telephone Consultative Committee 

CMIP Common Management Information Protocol 

EM Element Manager 

IRP Integration Reference Point 

ITU-T International Telecommunication Union, Telecommunication Sector 

M Mandatory 

MO Managed Object 
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MOC 
MOI 

NE 

NM 

NMC 

O 

OS 

OSI 

SS 

UML 



Managed Object Class 

Managed Object Instance 

Network Element 

Network Manager 

Network Management Centre 

Optional 

Operations System 

Open System Interconnection 

Solution Set 

Unified Modelling Language 



£75/ 



3GPP TS 32.111-2 version 3.4.0 Release 1999 



ETSI TS 132 111-2 V3.4.0 (2005-03) 



4 Basic aspects 

4.1 Background 

Integration Reference Points (IRPs) are the means within 3G Telecom Management (TM) for specifying interoperable 
points of information exchange between systems and applications. 

3GPP TS 32.101 [12] and 32.102 [13] contain background and introductory information about IRP. 



4.2 System Overview 



The following figures identify system contexts of this IRP in terms of implementations called IRP Agent and 
IRPManager. 

"IRPManager" depicts a process that interacts with IRP Agent for the purpose of receiving alarms via this IRP. 
Examples of IRPManagers can be Network Management Systems and Alarm viewing devices (such as a local craft 
terminal). IRP Agent implements and supports the Alarm IRP. 

IRP Agent can be one Network Element (NE) (see figure 2) or it can be one Element Manager (EM) with one or more 
NEs (see figure 1). In the latter case, the interfaces (represented by a thick dotted line) between the EM and the NEs are 
not subject of this IRP. Whether EM and NE share the same hardware system is not relevant to this IRP either. 

By observing the interaction across the Alarm IRP, one cannot deduce if EM and NE are integrated in a single system 
or if they run in separate systems. 

As indicated in figure 1 and figure 2, the subject IRP need to be complemented with the Notification IRP 
3GPP TS 32.106-2 [11] (to allow IRPManager to subscribe to notifications issued by IRP Agent) and (optionally) 
product-specific resource models describing the MOs maintained by IRP Agent. 



IRPManager 



NM 



IRP Agent 



NEs 



Itf-N 




EM 

Notification IRP 
Alarm IRP 



Figure 1 : System Context A 
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Figure 2: System Context B 
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IRP Information Service 



5.1 



Interfaces 



Figure 3 illustrates the operations and notifications defined as interfaces implemented and used by IRP Agent and 
IRPManager. In the present document the word "interface" is used to convey identical meaning as that defined within 
UML. Parameters and return status are not indicated. 

Two interfaces are defined. One is called AlarmlRPOperations. This interface defines operations implemented by 
IRP Agent and used (or called by) IRPManager. The other is called AlarmlRPNotif ication. This interface 
defines notification implemented by IRPManager and used by IRP Agent. 



IRPManager 



use 



«lnterface» 
AlarmlRPOperations 



•acknowledgeAlarmsO 

»unacknowledgeAlarms() 

^getAJarmListO 

RgetAJarmlRPVersionO 

^getAJarmCountQ 



«lnterface» 
Alarm IRPNotifications 



^notifyNewAlarm () 
♦notifyChangedAlarm () 
♦notifyAlarmListRebuiltO 
♦notifyAckStateChangedO 
♦notifyClearedAlarm () 



^-^ 



implement 



use 



IRP Agent 



Figure 3: Operations and Notification 



5.2 Operations of AlarmlRPOperations Interface 

5.2.1 Operation acknowledgeAlarms (M) 

IRPManager invokes this operation to acknowledge one or more alarms. IRPManager does not supply time of 
acknowledgement. If operation is successful, IRP Agent registers the time of operation in ackTime in Alarm 
Information in Alarm List. IRP Agent registers ackUser Id and ackSystemId in Alarm Information. It sets 
ackState to "acknowledged" as well. 

The ackTime, ackUserld, ackSystemId and ackState are collectively called Acknowledgement Information 
in the present document. 

IRP Agent shall send notifications about Acknowledgement Information to all IRPManagers in subscriptions. 

IRP Agent shall remove the Alarm Information whose perceivedSeverity is cleared and its Acknowledgement 

State is "acknowledged" from Alarm List. 
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Tablel : Parameters for acknowledgeAlarms 



Name 


Qualifier 


Purpose 


alarm 

Inf ormationR 

eferenceList 


Input, M 


It carries one or more identifiers identifying Alarm Information in Alarm List. Each 
identifier identifies at most one Alarm Information in Alarm List. 


AckUserld 


Input, M 


It identities the user acknowledging the alarm. It can be used to identify the human 
operator such as "John Smith" or it can identify a group, such as "Team Six". It may 
contain no information implying that IRPManager does not wish this information be kept 
in Alarm Information in Alarm List. 


ackSystemId 


Input, 


It identifies the processing system on which the subject IRPManager runs. It may 
contain no information implying that IRPManager does not wish this information be kept 
in Alarm Information in Alarm List. 


badAlarmlnfo 
rmationRef er 
enceList 


Output, M 


It identifies the Alarm Information that are not present in Alarm List or that they are 
present, but Acknowledgement Information has not changed, in contrast to 
IRPManager's request. Element of this list is a pair of Alarm Information Reference and 
reason. This parameter shall contain at least one element in case the output status 
indicates partial failure. Othenwise, it shall contain no information. 


status 


Output, M 


(a) Operation succeeded. Acknowledgement state of all Alarm Information (in 
Alarm List) identified by alarmlnformatlonReferenceLlst are "acknowledged" 
or 

(b) Operation failed. No change is made to Acknowledgement Information in any Alarm 
Information in Alarm List. Example of one such failure is when parameter 
alarmlnformatlonReferenceLlst Contains no identifier or no valid identifier or 

(c) Operation partially failed. It indicates that at least one but not all Alarm Information 
(in Alarm List) identified by parameter alarmlnformatlonReferenceLlst has 
changed its Acknowledgement Information according to IRPManager's request. In this 
case, the output parameter, called badAlarmlnformatlonReferenceLlst, shall 
contain a subset of the identifiers carried in parameter 

alarmlnformatlonReferenceLlst. 



5.2.2 Operation unacknowledgeAlarms (O) 

IRPManager invokes this operation to unacknowledge one or more alarms. 

If operation is successful, IRP Agent shall remove all Acknowledgement Information in Alarm Information in Alarm 
List. It shall send notifications carrying Acknowledgement Information to all IRPManagers (including the subject 
IRPManager) in subscriptions. The Acknowledgement Information carried shall contain ackUserld, ackxime and 
ackState. In addition it may contain ackSystemld. 

Table 2: Parameters for unacknowledgeAlarms 



Name 


Qualifier 


Purpose 


alarm 

InformationRefe 

renceList 


Input, M 


It carries one or more identifiers identifying Alarm Information in Alarm List. Each 
identifier identifies at most one Alarm Information in Alarm List. 


ackUserld 


Input, M 


It identities the user un-acknowledging the alarm. 


ackSystemld 


Input, 


It identifies the processing system on which the subject IRPManager runs. 


badAlarmlnf orma 
tionReferenceLi 
st 


Output, M 


It identifies the Alarm Information that are not present in Alarm List or that they are 
present, but Acknowledgement Information has not changed, in contrast to 
IRPManager's request. Element of this list is a pair of Alarm Information 
Reference and reason. This parameter shall contain at least one element in case 
the output status indicates partial failure. Otherwise, it shall contain no 
information. 
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Name 


Qualifier 


Purpose 


status 


Output, M 


(a) Operation succeeded. Acknowledgement state of the Alarm Information 
(in Alarm List) identified by alarmlnformationReferenceList is 
"unacknowledged" or 

(b) Operation failed. No change is made to Acknowledgement Information in any 
Alarm Information in Alarm List. Failure examples are (a) when parameter 
alarmlnformationReferenceList contains no identifier (b) it contains no 
valid identifier (c) its ackuserid and ackSystemid do not correspond to ones 
used in previous acknowiedgeAiarms operation. 

(c) Operation partially failed. It indicates that at least one but not all Alarm 
Information (in Alarm List) identified by parameter 

alarmlnformationReferenceList has changed its Acknowledgement 
Information according to IRPIVIanager's request. In this case, the output 
parameter, called badAlarmInf ormationRef erenceLlst, shall contain a 
subset of the identifiers carried in parameter 
alarmlnformationReferenceList. 



5.2.3 Operation getAlarmList (M) 

IRPManager requests IRP Agent to provide a list of alarms in Alarm List. These alarms can be provided as a sequence 
of single alarm notifications (asynchronous alarm alignment) or in a unique message containing all the alarms 
(synchronous alarm alignment). 

Table 3: Parameters of getAlarmList 



Name 


Qualifier 


Purpose 


alarmlnform 
ationList 


Output, IVl 


It carries Alarm Information in Alarm List. Implementation of this parameter is SS 
dependent. 


alarmAckSta 
te 


Input, 


It has five values indicating a) all alarms b) all active alarms c) all active and 
acknowledged alarms d) all active and un-acknowledged alarms e) all cleared and un- 
acknowledged alarms. 

If present, IRPAgent shall use it to apply on Alarm Information in Alarm List when 
constructing its output parameter alarminf ormationList. If input parameter filter 
is also present, the filter constraint carried in filter shall also be applied as well. 
If absent, IRPAgent shall return all Alarm Information in Alarm List subject to filter 
constraint expressed in filter parameter. 


filter 


Input, 


It carries a filter constraint. IRPAgent shall return Alarm Information that satisfies this 
filter constraint only. Filter constraint grammar is SS dependent. 

If parameter is absent and the alarm alignment is asynchronous, IRPAgent shall apply the 
current filter constraint used towards the IRPManager. 


status 


Output, M 


Operation succeeded in that alarminf ormationList contains the required Alarm 

Information, or 

(b) Operation failed because of specified or unspecified reason. 



5.2.4 Operation getAlarmCount (O) 

IRPManager wishes to know the amount of Alarm Information kept in IRPAgent. IRPManager requests IRPAgent to 
provide the counts via this operation. Possible usage is for IRPManager to find out the number of Alarm Information in 
Alarm List before invoking getAlarmList operation. 
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Table 4: Parameters for getAlarmCount 



Name 


Qualifier 


Purpose 


filter 


Input, 


It carries a filter constraint. IRPAgent shall return Alarm Information that 
satisfies this filter constraint only. Filter constraint grammar is SS dependent. 


alarmAckState 


Input, 


It has five values indicating a) all alarms b) all active alarms c) all active and 
acknowledged alarms d) all active and un-acknowledged alarms e) all cleared 
and un-acknowledged alarms. 

If present, IRPAgent shall apply it for counting. If input parameter filter is 
also present, IRPAgent shall apply the filter constraint for counting as well. 
If absent, IRPAgent shall count all Alarm Information, subject to filter constraint 
expressed in filter parameter. 


criticalCount, 

majorCount, 

minorCount, 

warningCount, 

indeterminateCoun 

t, clearedCount 


Output, M 


They specify the number of Alarm Information whose perceived severity 
are critical, major, minor, warning, indeterminate and Cleared 

respectively. 


status 


Output, M 


(a) Operation succeeded in that the counts returned are valid, or 

(b) Operation failed because of specified or unspecified reason. 



5.2.5 Operation getAlarmlRPVersion (M) 

IRPManager wishes to determine the IRP versions supported by the IRPAgent. IRPAgent shall return with a list of (one 
or more) version numbers currently supported. 

Table 5: Parameters of getAlarmiRPVersion 



Name 


Qualifier 


Purpose 


versionNumbe 
rList 


Output, IVI 


It indicates one or more SS version numbers supported by the IRPAgent. 


status 


Output, M 


(a) Operation succeeded in that IRPAgent is able to provide the list of version 
numbers. 

(b) Operation failed in that the IRPAgent is not able to provide the list of supported 
version numbers. 



5.3 



Notifications of AiarmiRPNotif ications Interface 



5.3.1 General 

Operations that IRPManager uses to manage subscription to receive notifications are specified in Notification IRP 

(3GPP TS 32.106-2 [11]). 3GPP TS 32.106-2 [11] also specifies a generic notification notify. 

3GPP TS 32.106-2 [11] defines a number of parameter-attributes that are commonly carried in notifications as well. 

The commonly carried parameter-attributes are collectively called notif IcationHeader in the present document. 
The parameter-attribute names and their qualifiers are listed in table 6. 

Table 6: Notification Header 



Parameter-Attributes defined in 3GPP TS 32.106-2 [11] 


Qualifier for use in this IS 


managedObject Class 


M 


managedObject Instance 


M 


notif icationld 


M 


eventXime 


M 


systemDN 


C 


eventXype 


M 


extendedEventXype 


M 
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The following subclauses define specific notifications relevant for Alarm IRP by extending notify in 
3GPPTS 32.106-2 [11]. 

5.3.2 Notification notifyNewAlarm (M) 

IRP Agent notifies the subscribed IRPManager that a new alarm has been added into the 5.4.1 Alarm List and that the 
added alarm satisfies the current filter constraint of the subscription. 

Table 7: Parameters of notifyNewAlarm 



Name 


Qualifier 


Comment 


notificationHeader 


Input, M 


See Table 6: Notification Header, 


alarmln format ionBody 


Input, M 


It contains information about the new alarm. 
See subclause 5.4.6 Alarm Information. 



5.3.3 Notification notifyChangedAlarm (O) 

IRP Agent notifies subscribed IRPManager regarding changes in perceived severity level (except the change to the 
perceived severity "cleared" which is handled by the notifyClearedAlarm notification) in Alarm Information in Alarm 
List. The Alarm Information carried in the notification shall satisfy the current filter constraint of the subscription. 

The information carried in this notification contains all attributes that are filterable and are present in the original 
notifyNewAlarm. 

Table 8: Parameters of notifyChangedAlarm 



Name 


Qualifier 


Purpose 


notificationHeader 


Input, M 


See Table 6: Notification Header 


alarmlnformat ionBody 


Input, M 


It contains information of the changed Alarm Information. 
See subclause 5.4.6 Alarm Information. 



5.3.4 Notification notifyAckStateChanged (M) 

IRP Agent notifies the subscribed IRPManager regarding changes in alarm Acknowledgement State in Alarm 
Information in Alarm List. The Alarm Information carried in the notification shall satisfy the current filter constraint of 
the subscription. 

If the alarm Acknowledgement State is changed to acknowledged, the Acknowledgement Information of the 
Alarm Information in Alarm List shall contain ackTime and ackState indicating "acknowledged". It may contain 
ackUser Id and ackSystemld. The Alarm Information carried in the notification shall contain identical set of 
parameters as well. 

If the Acknowledgement State is changed to "unacknowledged", the Acknowledgement Information of the 
Alarm Information in the Alarm List shall be absent or shall contain no information. The Alarm Information carried in 
the notification shall have the Acknowledgement Information. It shall contain ackUserld, ackTime and 
ackState indicating unacknowledged. It may contain ackSystemld. 

The information carried in this notification contains all attributes that are filterable and are present in the original 
notifyNewAlarm. 

Table 9: Parameters of notifyAckStateChanged 



Name 


Qualifier 


Purpose 


notificationHeader 


Input, M 


See Table 6: Notification Header 


alarmln format ionBody 


Input, IVl 


It contains the Alarm Information whose 
Acknowledgement State has changed. 
See subclause 5.4.6 Alarm Information. 
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Subclause 6.1 specifies the Alarm States and some of these states relate to Acknowledgement State. 

5.3.5 Notification notifyClearedAlarm (M) 

IRP Agent notifies the subscribed IRPManager of alarm clearing if the subject Alarm Information satisfies the optional 
filter constraint expressed in the subscribe operation. 

IRP Agent shall remove the Alarm Information whose perceivedSeverity is cleared and its Acknowledgement 

State is "acknowledged" from Alarm List. 

The information carried in this notification contains all attributes that are filterable and are present in the original 
notifyNewAlarm. 

Table 10: Parameters for notifyClearedAlarm 



Name 


Qualifier 


Purpose 


notification 
Header 


Input, M 


See Table 6: Notification Header 


alarmlnf ormatio 
nBody 


Input, M 


It contains Alarm Information whose perceivedSeverity is cleared. 
Additionally, the Alarm Information may contain correlatedNotification 
(defined in 3GPP TS 32.106-2 [11]) that contains references to other 
Alarm Information whose perceivedSeverity levels are cleared as well. 
Alternatively, it contains an Alarm Information containing a 
correlatedNotification (defined in 3GPP TS 32.106-2 [11]) that contains 
references to other Alarm Information whose perceivedSeverity levels 
are cleared. 
See subclause 5.4.6 Alarm Information 



5.3.6 Notification notifyAlarmListRebuilt (M) 

IRP Agent maintains an Alarm List. If IRP Agent rebuilds this list for any reason, the IRP Agent shall notify 
IRPManager after the Alarm List is rebuilt. The conditions under which IRP Agent shall rebuild and the means by 
which IRP Agent shall rebuild its Alarm List are outside the scope of this IRP. 

Table 11 : Parameters for notifyAlarmListRebuilt 



Name 


Qualifier 


Purpose 


notification 
Header 


Input, IVI 


See Table 6: Notification Header 


reason 


Input, M 


It provides Alarm List rebuilt reason. One valid reason is "indeterminate". 



5.4 



Beliaviour 



5.4.1 Alarm List 

IRP Agent maintains an Alarm List. It contains all currently active alarms (i.e. Alarm Information whose 
perceivedSeverity is not Cleared) and alarms that are Cleared but not yet acknowledged. When an alarm is 
Cleared and is acknowledged, its corresponding Alarm Information in this Alarm List is removed. The removed Alarm 
Information shall no longer be accessible via this IRP. 

IRP Agent shall create a new Alarm Information in Alarm List whenever an alarm is emitted (internally within 
IRP Agent) that does not match with any alarm in the Alarm List. In this case, after the creation of the new Alarm 
Information, IRP Agent invokes notifyNewAlarm operation. 

IRP Agent shall not create a new Alarm Information in Alarm List when an alarm is emitted (internally within 
IRP Agent) that matches with an alarm in the Alarm List. In this case, IRP Agent shall invoke either 

(1) notifyChangedAlarm or (2) notifyClearedAlarm followed by notifyNewAlarm operation. 
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See Annex D for specification of alarm matching criterion. 

In the case of a matched Alarm Information the following additional rule shall apply: 

• IRP Agent shall remove all information in Acknowledgement Information of the subject Alarm Information. 

The Acknowledgement State shall be "unacknowledged". IRP Agent updates the eventTime and 
perceivedSeverity of the matched Alarm Information. IRP Agent invokes notifyChangedAlarm 
notification to all subscribed IRPManagers. 

5.4.2 Network Resource Name 

An alarm provides the alarm information of a specific network resource. Alarms use one parameter-attribute, Managed 
Object Instance (MOI), to identify the network resource. The semantics of MOI is defined in ITU-T Recommendation 
X.720 [8]. The MOI shall be unique within a certain context, such as a transmission network or a switching network. 
This IRP does not specify the context. 

The encoding of MOI parameter-attribute value is SS dependent and is specified in ITU-T Recommendation X.720 [8] 
and 3GPPTS 32.106-8 [14]. 

5.4.3 Alarm Information Identification 

Since IRPManager can acknowledge and unacknowledge Alarm Information currently kept in Alarm List of IRP Agent, 
there is a need to establish a convention so IRPManager and IRP Agent can unambiguously identify Alarm Information 
in Alarm List. 

Since IRP Agent can generate notifications about the state change (e.g. perceivedSeverity level changes or 
Acknowledgement State changes) of an Alarm Information in Alarm List, there is a need to establish a 
convention so IRPManager and IRP Agent can unambiguously identify the Alarm Information whose state has changed. 

The convention, to identify Alarm Information, is the subject of this subclause. 

5.4.3.1 Use of alarm Information Reference 

An alarmlnf ormationRef erence (AIR) unambiguously identifies one Alarm Information in IRP Agent's Alarm 
List. One IRP Agent has one Alarm List. The IRP Agent assigns AIR for the Alarm Information in its own Alarm List. 

IRP Agent includes AIR in all notifications it emits. 

IRPManager shall include AIR(s) in acknowledgeAlarms and unacknowledgeAlarms. 

The mapping of AIR into its equivalents in respectively SS are done in Annex D. 



5.4.4 Alarm loss (detection ar\6 recovery 



This IRP does not specify methods for IRPManager to detect alarm loss. The use of alarmld (see subclause 4.4.3.1) 
to detect alarm loss is an arrangement made between IRP Agent and IRPManager. This arrangement is outside the 
scope of this IRP. For example, IRP Agent may use integer sequence (e.g. 1, 2, 3, 4, 5...) as alarmlds for its alarms. 
Based on this knowledge, IRPManager can detect alarm loss. This kind of arrangement may not be possible for all SS. 

This IRP does not specify if IRP Agent can determine if IRPManager has received alarms correctly. Not all SSs provide 
such capability. 

This IRP does not specify methods for IRPManager and IRP Agent to recover alarm loss. The only mechanism 
recommended to deal with alarm loss is the use of getAlarmList operation. This IRP does not specify conditions 
under which IRPManager should invoke this operation. 

5.4.5 Alarm List loss 

IRP Agent can lose confidence in the integrity of its Alarm List. Under this condition, IRP Agent shall invoke 

not IfyAlarmLi St Rebuilt notification after it has successfully rebuilt the Alarm List. 
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5.4.6 Alarm Information 

This subclause specifies the information contained in Alarm Information. 

Alarm Information(s) are stored in Alarm List. They are carried in notif yNewAlarm, notif yChangedAlarm, 
notifyAckStateChanged, notif yClearedAlarm. They are also carried in the response to 
getAlarmList operation. 

When it is carried in notifyChangedAlarm notification, it indicates that one or more parameter-attribute values of 
the Alarm Information have changed since the most recent notif yNewAlarm or notifyChangedAlarm 
notification on the subject alarm. 

Alarm Information, carried in notifications, always contains the AIR. In notifyNewAlarm, the AIR is used to 

identify the active Alarm Information carried in the notification. In notifyChangedAlarm and 

notif yClearedAlarm, the AIR is used to identify the active Alarm Information whose state has changed. 

In notif yAckStateChangedAlarm, the AIR is used to identify the Alarm Information (active or inactive) in the 
Alarm List whose acknowledgement state has changed. 

Alarm Information contains the notif icationHeader and alarmlnf ormationBody. Table 6 defines 
parameter-attributes of notif icationHeader. Table 13 defines the parameter-attributes of 

alarmlnf ormationBody. 

Letter M and O stands for Mandatory and Optional respectively. 
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Table 13: Parameter-Attributes of alarminformationBody 



Name 


Qualifier 


Comment 


probable 
Cause 


M 


It qualifies alarm and provides further information than eventType. See Annex B 
for a complete listing. This list is extensive. It is recommended that IRPAgent should 
use the list as is and not to extend it. It is noted that IRPAgent can privately (outside 
the scope of this IRP) define values for specif icProbiem that provides semantics 
not conveyed by probabieCause. A special probable cause value (SS specific, e.g. 
-1) indicates that this alternative is valid. This parameter-attribute value shall be 
single-value and of simple type such as integer or string. See definition in ITU-T 
Recommendation X.733 [2] subclause 8.1.2.1. 


perceived 
Severity 


M 


It indicates the relative level of urgency for operator attention. . Legal values are 

Critical, Major, Minor, Warning, Indeterminate and Cleared, 
according to ITU-T Recommendation X.733 [2]. This IRP does not recommend the 
use of indeterminate. 


specific 
Problem 





It provides further qualification on the alarm than probabieCause. This parameter- 
attribute value shall be single-value and of simple type such as integer or string. See 
definition in ITU-T Recommendation X.733 [2] subclause 8.1.2.2. 


correlated 
Notifications 





It identifies a set of notifications to which this notification is considered to be 
correlated. See definition in ITU-T Recommendation X.733 [2] subclause 8.1 .2.9. 


backedUpStatu 
s 





It indicates if an object has a back up. See definition in ITU-T Recommendation 
X.733 [2] subclause 8.1.2.4. 


backUpObject 





It carries the DN of the back up object. It shall be absent if backUpStatus is absent 
or its value indicates false. See definition in ITU-T Recommendation X.733 [2] 
subclause 8.1.2.5. 


trend 
Indication 





It indicates if some observed condition is getting better, worse, or not changing. 
Legal values are "less severe", "no change" and "more severe". See definition in 
ITU-T Recommendation X.733 [2] subclause 8.1.2.8. 


threshold 
Info 





It indicates if the threshold crossed was in the up or down direction. See definition in 
ITU-T Recommendation X.733 [2] subclause 8.1.2.7. 


stateChange 
Definition 





It indicates MO attribute value changes. See definition in ITU-T Recommendation 
X.733 [2] subclause 8.1.2.10. 


monitored 
Attributes 





It indicates MO attributes whose value changes are being monitored. See definition 
in ITU-T Recommendation X.733 [2] subclause 8.1 .2.1 1 . 


proposed 

Repair 

Actions 





It indicates proposed repair actions. See definition in ITU-T Recommendation X.733 
[2] subclause 8.1.2.12. 


additional 
Text 





It provides the identity of the NE (e.g. RNC, Node-B) from which the alarm has been 
originated. It corresponds to the "user label" attribute of the MOC representing the 
NE in the Basic CM IRP Information Model. 
It can contain further information on the alarm. 


additional 
Information 


(see next 
column) 


It carries additional information related to the subject Alarm Information. It may 

contain the following parameter-attributes. 

Alarmld: It identifies at most one Alarm Information in the Alarm List. See subclause 

5.4.3.1 . Use of this parameter-attribute is SS dependent. 

ackTime: It identifies the time of last operation acknowledgeAlarms or 

unacknowledgeAlarms. It is mandatory for notifyAckStateChanged notification and 

getAlarmList operation, it is optional for other notifications. 

ackUserld: It identifies the last user who has change the Acknowledgement State via 

operation acknowledgeAlarms or unacknowledgeAlarms. It is mandatory for 

notifyAckStateChanged notification and getAlarmList operation, it is optional for other 

notifications. 

ackSystemId: It identifies the system in which IRPManager, that invokes the 

acknowledgeAlarms or unacknowledgeAlarms operation, runs. It is mandatory for 

getAlarmList operation, optional for all notifications. 

ackState: It identifies the Acknowledgement State of the alarm. Its valid values are 

"acknowledged" and "unacknowledged". It is mandatory for notifyAckStateChanged 

notification and getAlarmList operation, it is optional for other notifications. 
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Dynamic Model 



6.1 



Alarm states 



Alarms have states. Figure 4 illustrates the alarm states. 

The triggers "MO emits..." are internal within IRP Agent and are not observable via the Alarm IRP. Other triggers, e.g 
"acknowledgeAlarms", are observable via the Alarm IRP. 

The solid circle icon represents the Start State. The double circle icon represents the End State. In this state, 
the alarm is cleared and acknowledged. The alarm shall not be accessible via the IRP and is removed from the Alarm 
List. 



MO emits changed 
alarm 



1 



MO emits unack&unclear 
new alarm 

> 



A 



MO emits 
alarm changed 



acknowledgeAlarms 



MO emits 
alarm cleared 




ack&unclear 



^ 

unack&clear 



MO emits changed alarm^ 



acknowledgeAlarms 



MO emits 
alarm cleared 



^ 



ack&clear state. Alarm 
Information is no longer 
accessible via this IRP. 



Figure 4: Alarm States 
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Annex A (normative): 

Event Types and Extended Event Types 

This annex lists and explains event types and extended event types used by Alarm IRP and then lists the event types and 
extended event types valid for each notification in the Alarm IRP. 

Event type is carried by a parameter called eventType defined in 3GPP TS 32.106-2 [11]. 

Extended event types is carried by a parameter called extendedEventType defined in 3GPP TS 32.106-2 [11]. 

Encoding of eventType and extendedEventType is SS dependent. For example, the value of eventType 
can be encoded as Object Identifier in CMIP SS and as numeric string in CORBA SS. 

The tables below may be extended in the future. 

Table A.I : Event Types 



Event Types 


Explanation 


Communications Alarm 


An alarm of this type is associated with the procedure and/or process required conveying 
information from one point to another (ITU-T Recommendation X.733 [2]). 


Processing Error Alarm 


An alarm of this type is associated with a software or processing fault (ITU-T Recommendation 
X.733 [2]). 


Environmental Alarm 


An alarm of this type is associated with a condition related to an enclosure in which the equipment 
resides (ITU-T Recommendation X.733 [2]). 


Quality of Service 
Alarm 


An alarm of this type is associated with degradation in the quality of a service (ITU-T 
Recommendation X.733 [2]). 


Equipment Alarm 


An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733 [2]). 



Table A.2: Extended Event Types 



Extended Event Types 


Explanation 


New Alarm 


A notification of this type indicates that a new alarm has occurred. 


Changed Alarm 


A notification of this type indicates that one or more attributes, excepting those related to 
acknowledgement state, of an active alarm have changed. 


Acknowledgement State 
Changed 


A notification of this type indicates that the acknowledgement state of an alarm has 
changed. 


Cleared Alarm 


A notification of this type indicates that an alarm has been cleared and is no longer 
active. 


Alarm List Rebuilt 


A notification of this type indicates that the Alarm List has been successfully rebuilt. 



Table A.3: Event Types and Extended Event Types applicable to each Notification 



Notification 


Event Type 


Extended Event type 


notifyNew Alarm 


Communications Alarm 
Processing Error Alarm 
Environmental Alarm 
Quality of Service Alarm 
Equipment Alarm 


New Alarm 


notifyChangedAlarm 


same as for notifyNewAlarm 


Changed Alarm 


notify AckStateChanged 


same as for notifyNewAlarm 


Acknowledgement State Changed 


noli fyClearedAl arm 


same as for notifyNewAlarm 


Cleared Alarm 


notify AlarmLi stRebuilt 




Alarm List Rebuilt 
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Annex B (normative): 
Probable Causes 



This annex lists probable causes and their corresponding event types. 

Sources of these probable causes are ITU-T Recommendation M.3100 [9], ITU-T Recommendation X.721 [3], ITU-T 
Recommendation X.733 [2], ITU-T Recommendation X.736 [4] and GSM 12.11 [10]. 

The list may be extended in the future, e.g. with UMTS-specific probable causes. 

Table B.I: Probable Causes from ITU-T Recommendation M.3100 [9] 



IVI.3100 Probable cause 


Event type 


Indeterminate 


Unknown 


Alarm Indication Signal (AIS) 


Communications 


Call Setup Failure 


Communications 


Degraded Signal 


Communications 


Far End Receiver Failure (FERF) 


Communications 


Framing Error 


Communications 


Loss Of Frame (LOF) 


Communications 


Loss Of Pointer (LOP) 


Communications 


Loss Of Signal (LOS) 


Communications 


Payload Type Mismatch 


Communications 


Transmission Error 


Communications 


Remote Alarm Interface 


Communications 


Excessive Bit Error Rate (EBER) 


Communications 


Path Trace Mismatch 


Communications 


Unavailable 


Communications 


Signal Label Mismatch 


Communications 


Loss Of Multi Frame 


Communications 


Back Plane Failure 


Equipment 


Data Set Problem 


Equipment 


Equipment Identifier Duplication 


Equipment 


External IF Device Problem 


Equipment 


Line Card Problem 


Equipment 


Multiplexer Problem 


Equipment 


NE Identifier Duplication 


Equipment 


Power Problem 


Equipment 


Processor Problem 


Equipment 


Protection Path Failure 


Equipment 


Receiver Failure 


Equipment 


Replaceable Unit Missing 


Equipment 


Replaceable Unit Type Mismatch 


Equipment 


Synchronisation Source Mismatch 


Equipment 


Terminal Problem 


Equipment 


Timing Problem 


Equipment 


Transmitter Failure 


Equipment 


Trunk Card Problem 


Equipment 


Replaceable Unit Problem 


Equipment 


Air Compressor Failure 


Environmental 


Air Conditioning Failure 


Environmental 


Air Dryer Failure 


Environmental 


Battery Discharging 


Environmental 


Battery Failure 


Environmental 


Commercial Power Failure 


Environmental 


Cooling Fan Failure 


Environmental 


Engine Failure 


Environmental 


Fire Detector Failure 


Environmental 


Fuse Failure 


Environmental 


Generator Failure 


Environmental 


Low Battery Threshold 


Environmental 


Pump Failure 


Environmental 
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M.3100 Probable cause 


Event type 


Rectifier Failure 


Environmental 


Rectifier Higli Voltage 


Environmental 


Rectifier Low F Voltage 


Environmental 


Ventilation System Failure 


Environmental 


Enclosure Door Open 


Environmental 


Explosive Gas 


Environmental 


Fire 


Environmental 


Flood 


Environmental 


High Humidity 


Environmental 


High Temperature 


Environmental 


High Wind 


Environmental 


Ice Build Up 


Environmental 


Intrusion Detection 


Environmental 


Low Fuel 


Environmental 


Low Humidity 


Environmental 


Low Cable Pressure 


Environmental 


Low Temperature 


Environmental 


Low Water 


Environmental 


Smoke 


Environmental 


Toxic Gas 


Environmental 


Storage Capacity Problem 


Processing error 


Memory IVIismatch 


Processing error 


Corrupt Data 


Processing error 


Out Of CPU Cycles 


Processing error 


Software Environment Problem 


Processing error 


Software Download Failure 


Processing error 
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Table B.2: Probable Causes from ITU-T Recommendation X.721 [3] / 
ITU-T Recommendation X.733 [2] 



X.733 Probable Cause 


Event type 


Adapter Error 


Equipment 


Application Subsystem Failure 


Processing error 


Bandwidth Reduction 


Ouality of service 


Call Establishment Error 


Communications 


Communication Protocol Error 


Communications 


Communication Subsystem Failure 


Communications 


Configuration or Customizing Error 


Processing error 


Congestion 


Ouality of service 


Corrupt Data 


Processing error 


CPU Cycles Limit Exceeded 


Processing error 


Data Set or IVIodem Error 


Equipment 


Degraded Signal 


Communications 


DTE-DCE Interface Error 


Communications 


Enclosure Door Open 


Environmental 


Equipment Malfunction 


Equipment 


Excessive Vibration 


Environmental 


File Error 


Processing error 


Fire Detected 


Environmental 


Flood Detected 


Environmental 


Framing Error 


Communications 


Heating or Ventilation or Cooling System Problem 


Environmental 


Humidity Unacceptable 


Environmental 


Input/Output Device Error 


Equipment 


Input Device Error 


Equipment 


LAN Error 


Communications 


Leak Detection 


Environmental 


Local Node Transmission Error 


Communications 


Loss of Frame 


Communications 


Loss of Signal 


Communications 


Material Supply Exhausted 


Environmental 


Multiplexer Problem 


Equipment 


Out of Memory 


Processing error 


Output Device Error 


Equipment 


Performance Degraded 


Ouality of service 


Power Problem 


Equipment 


Pressure Unacceptable 


Environmental 


Processor Problem 


Equipment 


Pump Failure 


Environmental 


Oueue Size Exceeded 


Ouality of service 


Receive Failure 


Equipment 


Receiver Failure 


Equipment 


Remote Node Transmission Error 


Communications 


Resource at or Nearing Capacity 


Quality of service 


Response Time Excessive 


Ouality of service 


Re-transmission Rate Excessive 


Ouality of service 


Software Error 


Processing error 


Software Program Abnormally Terminated 


Processing error 


Software Program Error 


Processing error 


Storage Capacity Problem 


Processing error 


Temperature Unacceptable 


Environmental 


Threshold Crossed 


Quality of service 


Timing Problem 


Equipment 


Toxic Leak Detected 


Environmental 


Transmit Failure 


Equipment 


Transmitter Failure 


Equipment 


Underlaying Resource Unavailable 


Processing error 


Version Mismatch 


Processing error 
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Table B.3: Probable Causes from GSM 12.11 [10] 



GSM 12.11 Probable Cause 


Event Type 


A-bis to BIS interface failure 


Equipment 


A-bis to TRX interface failure 


Equipment 


Antenna problem 


Equipment 


Battery breakdown 


Equipment 


Battery charging fault 


Equipment 


Clock synchronisation problem 


Equipment 


Combiner problem 


Equipment 


Disk problem 


Equipment 


Equipment failure 


Equipment 


Excessive receiver temperature 


Equipment 


Excessive transmitter output power 


Equipment 


Excessive transmitter temperature 


Equipment 


Frequency hopping degraded 


Equipment 


Frequency hopping failure 


Equipment 


Frequency redefinition failed 


Equipment 


Line interface failure 


Equipment 


Link failure 


Equipment 


Loss of synchronisation 


Equipment 


Lost redundancy 


Equipment 


IVIains breakdown with battery back-up 


Equipment 


IVIains breakdown without battery back-up 


Equipment 


Power supply failure 


Equipment 


Receiver antenna fault 


Equipment 


Receiver Failure 


Equipment 


Receiver multicoupler failure 


Equipment 


Reduced transmitter output power 


Equipment 


Signal quality evaluation fault 


Equipment 


Timeslot hardware failure 


Equipment 


Transceiver problem 


Equipment 


Transcoder problem 


Equipment 


Transcoder or rate adapter problem 


Equipment 


Transmitter antenna failure 


Equipment 


Transmitter antenna not adjusted 


Equipment 


Transmitter failure 


Equipment 


Transmitter low voltage or current 


Equipment 


Transmitter off frequency 


Equipment 


Database inconsistency 


Processing error 


File system call unsuccessful 


Processing error 


Input parameter out of range 


Processing error 


Invalid parameter 


Processing error 


Invalid pointer 


Processing error 


IVIessage not expected 


Processing error 


Message not initialised 


Processing error 


IVIessage out of sequence 


Processing error 


System call unsuccessful 


Processing error 


Timeout expired 


Processing error 


Variable out of range 


Processing error 


Watch dog timer expired 


Processing error 


Cooling system failure 


Environmental 


External equipment failure 


Environmental 


External power supply failure 


Environmental 


External transmission device failure 


Environmental 


Fan failure 


Environmental 


High humidity 


Environmental 


High temperature 


Environmental 


Intrusion detected 


Environmental 


Low humidity 


Environmental 


Low temperature 


Environmental 


Smoke detected 


Environmental 


Excessive Error Rate 


Quality of service 


Reduced alarm reporting 


Quality of service 


Reduced event reporting 


Quality of service 
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GSM 12.11 Probable Cause 


Event Type 


Reduced logging capability 


Quality of service 


System resources overload 


Quality of service 


Broadcast channel failure 


Communications 


Connection establishment error 


Communications 


Invalid message received 


Communications 


Invalid IVISU received 


Communications 


LAPD link protocol failure 


Communications 


Local alarm indication 


Communications 


Remote alarm indication 


Communications 


Routing failure 


Communications 


SS7 protocol failure 


Communications 


Transmission error 


Communications 



Table B.4 identifies probable causes that are defined by more than one standard. This is for information only. 

Table B.4: Duplicated Probable Causes 



Duplicated Probable Cause 


GSM 12.11 


X.721 X.733 


M.31 00 


Event Type 


Call Establishment Failure {X.721/X.733) 
Call Setup Failure (M.31 00) 




X 


X 


Communications 


Degraded Signal 




X 


X 


Communications 


Framing Error 




X 


X 


Communications 


Loss of Frame 




X 


X 


Communications 


Loss of Signal 




X 


X 


Communications 


Equipment Failure (GSM 12.11) 
Equipment Malfunction {X.721/X.733) 


X 


X 




Equipment 


IVIultiplexer Problem 




X 


X 


Equipment 


Power Problem 




X 


X 


Equipment 


Processor Problem 




X 


X 


Equipment 


Receiver Failure 


X 


X 


X 


Equipment 


Timing Problem 




X 


X 


Equipment 


Transmitter Failure 


X 


X 


X 


Equipment 


Enclosure Door Open 




X 


X 


Environmental 


Fan Failure (GSIV1 12.11) 
Cooling Fan Failure (M.31 00) 


X 




X 


Environmental 


Fire Detected (X.721/X.733) 
Fire (M.31 00) 




X 


X 


Environmental 


Flood Detected (X.721/X.733) 
Flood (M.31 00) 




X 


X 


Environmental 


High Humidity 


X 




X 


Environmental 


High Temperature 


X 




X 


Environmental 


Intrusion Detected (GSM 12.11) 
Intrusion Detection (X.736/M.3100) 


X 




X 


Environmental 


Low Humidity 


X 




X 


Environmental 


Low Temperature 


X 




X 


Environmental 


Pump Failure 




X 


X 


Environmental 


Smoke Detected (GSM 12.11) 
Smoke (M.31 00) 


X 




X 


Environmental 


Storage Capacity Problem 




X 


X 


Processing Error 


Excessive Bit Error Rate (M.31 00) 
Excessive Error Rate (GSM 12.11) 
Excessive Error Rate 


X 




X 


Communications 
(M.31 00) 

Quality of Service 
(GSM 12.11/M.3100) 


Corrupt Data 




X 


X 


Processing Error 
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Annex C (informative): 

Examples of using notifyChangedAlarm 

This annex describes a number of valid and invalid interactions governing the case when IRP Agent is reporting a 
specific fault of a particular network resource whose alarm severity level changes from, e.g. "Critical" to "Minor" and 
then to "Cleared". 

In the following examples: 

ni is notif icationid, 

moc is managedOb jectClass, 

moi is managedOb jectlnstance, 

et is eventType, 

pc is probableCause, 

sp is specif icProblem, 

ps is perceivedSeverity and 

ai isAlarmld. 

EXAMPLE 1 : Valid sequence 1 to support the hypothetical case: 

(l)NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 
(2) NotifyChangedAlarm 

{ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 
(3) NotifyClearedAlarm 

(ni=3, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Cleared) 

EXAMPLE 2: Valid sequence 2 to support the hypothetical case: 

(1) NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyClearedAlarm 

(ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Cleared) 

(3) NotifyNewAlarm 

(ni=3, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

(4) NotifyClearedAlarm 

{ni=4, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Cleared) 

EXAMPLE 3: Invalid sequence 1 to support the hypothetical case: 
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(1) NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyChangedAlarm 

(ni=2, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

(3) NotifyClearedAlarm 

(ni=3, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Cleared) 
Interaction (2) is illegal since it uses a different ai for the same alarm. It should use ai=X as in interaction (1). 

EXAMPLE 4: Invalid sequence 2 to support the hypothetical case: 

(1) NotifyNewAlarm 

{ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyNewAlarm 

(ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

Interaction (2) is illegal since it invokes notifyNewAlarm using same ai value. It should use 

notifyChangedAlarm with the same ai value. 
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Annex D (normative): 

Mapping of Alarm Information Reference to its Solution Set 

Equivalents 

This annex specifies the mapping of AIR into its SS equivalents. It also specifies the conditions under which these 
attributes shall be used in the mapping process. 

Currently, there are two methods to map AIR into SS equivalents. 

One method is the use of managedOb jectlnstance and notif icationid whose semantics are defined by 

ITU-T. 

The other method is the use of alarmld whose semantics is identical to AIR. 

Table D.l specifies how identification of Alarm Information is achieved, with and without the use of alarmld. 

Table D.l : AIR Mapping Process 





Alarmld is USed 


Alarmld is not used 


Acknowledg 
eAlarm, 
unacknowle 
dgeAlarm 


IRPManager places value of alarmld of 
the received notif yNewAlarm or 
related notifyChangedAlarm or 
related notifyClearedAlarm (they 
shall have the same value) in AIRs of 
alarmlnformationReferenceList 
of this operation. 
IRPManager can place multiple values. 


IRPManager places values of 
managedOb jectlnstance and 
notif icationid of the received 
notifyNewAlarm notification in AIRs of 
alarmlnformationReferenceList of this 
operation. 

IRPManager can place multiple pairs of values. 


notif yNewA 
larm 


IRP Agent assigns a new alarmld for this 
notification. 

AIR is mapped to this alarmld. 

IRP Agent creates a new Alarm Information. 
This new Alarm Information is classified as 

active. 


IRP Agent assigns anew notif icationid to this 
notification. 

AIR is mapped to the managedOb jectlnstance 
and the notif icationid of this notification. 

IRP Agent creates a new Alarm Information. This new 
Alarm Information is classified as active. 


notifyChan 
gedAlarm 


IRP Agent uses the same alarmld of the 
related notif yNewAlarm for the 
alarmld of this notification. 

AIR is mapped to this alarmld. 

IRP Agent shall not create a new Alarm 
Information. 


IRP Agent assigns anew notif icationid to this 
notification. 

AIR is mapped to the matching-criteria-attributes 
(defined below) of this notification. The value of this 
set of attributes shall be identical to that of one active 
Alarm Information in the Alarm List. 

IRP Agent shall not create a new Alarm Information. 


notifyClea 
redAlarm 


IRP Agent uses the same alarmld of the 
related notif yNewAlarm for the 
alarmld of this notification. 

AIR is mapped to this alarmld. 

The IRP Agent shall not create a new Alarm 
Information. 

IRP Agent cannot indicate alarm clearing of 
more than one Alarm Information. 


IRP Agent assigns a new notificationid to this 
notification. 

IRP Agent shall not create a new Alarm Information 

AIR is mapped to the matching-criteria-attributes of 
this notification. The value of this set of attributes 
shall be identical to that of one active Alarm 
Information in the Alarm List. Additionally (in the 
same notification), IRP Agent may use 
correlatedNotifications to carry AIRs of 
other active Alarm Information whose 
perceivedSeverity is now set to Cleared as well, 
(in accordance to ITU-T Recommendation X.733 [2]) 
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Alarmld iS USed 


Alarmld is not used 






or 

IRP Agent shall use correlatedNotifications exclusively 
to carry AIRs of active Alarm Information whose 
perceivedSeverity is now set to Cleared, (in accordance 
with ITU-T Recommendation Q821 [1]). 


notifyAckS 
tateChange 
d 


IRP Agent uses the same alarmld of the 
related notif yNewAlarm for the 
alarmld of this notification. 

AIR is mapped to this alarmld. 

The IRP Agent shall not create a new Alarm 

Information. 

IRP Agent cannot indicate 

Acknowledgement State change of more 

than one Alarm Information. 


IRPAgent assignes a new notif icationid to this 

notification . 

IRPAgent shall not create a new Alarm Information. 

AIR is mapped to the matching-criteria-attributes of 
this notification. The value of this set of attributes 
shall be identical to that of the active Alarm 
Information in the Alarm List. Additionally (in the 
same notification), IRPAgent may use 
correlatedNotifications to carry AIRs of 
other Alarm Information whose Acknowledgement 
State has changed as well, (in accordance to ITU-T 
Recommendation X.733 [2]) 
or 

IRPAgent shall use correlatedNotifications 
exclusively to carry AIRs of Alarm Information whose 
Acknowledgement State has changed, (in 
accordance to ITU-T Recommendation Q821 [1]). 



D.1 Matching-Criteria-Attributes 

This clause identifies attributes that are defined in ITU-T Recommendation X.733 [2] as the matching-criteria- 
attributes. The attributes are: 

• managedOb jectlnstance 

• eventType 

• probableCause 

• specif icProblem, if present 



£75/ 



3GPP TS 32.111-2 version 3.4.0 Release 1999 



30 



ETSI TS 132 111-2 V3.4.0 (2005-03) 



Annex E (informative): 
Change history 



Change history 
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TSG# 


TSG Doc. 


CR 
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Subject/Comment 


Old 


New 


Mar 2000 


SA 07 


SP-000012 


- 


- 


Approved at TSG SA #7 and placed under Change Control 


2.0.0 


3.0.0 


Mar 2000 


-- 


-- 


- 


- 


Cosmetic 


3.0.0 


3.0.1 


Jun 2000 


SA_08 


SP-000250 


004 


— 


Split of TS - Part 2: Alarm Integration Reference Point (IRP): 
Information Service (IS) 


3.0.1 


3.1.0 


Sep 2000 


-- 


-- 


- 


- 


Cosmetic 


3.1.0 


3.1.1 


Sep 2000 


SA 09 


SP-000438 


001 


- 


Correction of qualifier for System DN 


3.1.1 


3.2.0 


Sep 2000 


SA 09 


SP-000438 


002 


- 


Addition of a missing constraint In acknowledgeAlarm operation 


3.1.1 


3.2.0 


Dec 2000 


SA 10 


SP-000520 


003 


- 


Incorrect modifiable attributes 


3.2.0 


3.3.0 


Dec 2000 


SA 10 


SP-000520 


004 


- 


Add acknowledgement Information to getAlarmLlst result 


3.2.0 


3.3.0 


Dec 2000 


SA_10 


SP-000520 


005 


- 


Identification of valid Event Types and Extended Event Types 
withiin Notifications 


3.2.0 


3.3.0 


Dec 2000 


SA_10 


SP-000520 


006 


- 


A cleared Alarm shiall be given perceived severity "Cleared" and 
nothiing else 


3.2.0 


3.3.0 


Dec 2000 


SA 10 


SP-000520 


007 


- 


Inconsistent behiaviour for cleared not yet acknowledged alarms 


3.2.0 


3.3.0 


Mar 2005 


SA 27 


SP-050021 


038 


- 


Inclusion of additional event types for duplicate probable causes 


3.3.0 


3.4.0 
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